home *** CD-ROM | disk | FTP | other *** search
/ Super Hot Shareware / Digital Concepts Inc. - PC World - SUPER HOT SHAREWARE.iso / Win98 / Msie540 / dcom95.exe / RCDATA / CABINET / relnotes.txt < prev    next >
Text File  |  1999-03-09  |  29KB  |  708 lines
  1. DCOM95 1.3
  2. Release Notes
  3. Last Modified: September 14, 1998
  4.  
  5. DCOM95 provides Distributed COM support for Microsoft« Windows« 95.
  6. The DCOM wire protocol transparently provides support for reliable, 
  7. secure, and efficient communication between Component Object 
  8. Model (COM) components such as ActiveX« controls, scripts, and 
  9. Java applets residing on different machines in a LAN, a WAN, or on 
  10. the Internet. With DCOM, your application can be distributed across 
  11. locations that make the most sense to your customer and to the 
  12. application.
  13.  
  14. For more in-depth information, see the DCOM Technical overview 
  15. available on the Microsoft COM home page, 
  16. http://www.microsoft.com/com/.
  17.  
  18. Contents
  19. ========
  20. I.   New Features
  21. II.  Bug Fixes
  22. III. Known Issues
  23. IV.  Differences from DCOM on Windows NT
  24. V.   Redistribution
  25. VI.  Support & Resources
  26. VII. File List
  27.  
  28. I. New Features
  29. ---------------
  30.  
  31. Replacing DCOM95 with Older Version Prohibited
  32.  
  33. In previous releases of DCOM95, you could replace a newer 
  34. version of DCOM95 with an older version of DCOM95. Version 
  35. numbers are now checked on installation, and you are not 
  36. permitted to install an older version over a newer version. This 
  37. change will avoid problems with incompatible versions of DLLs.
  38.  
  39. Visual Studio 6.0 Process Monitoring Support
  40.  
  41. In support of Visual Studio 6.0, DCOM95 provides monitoring 
  42. information for developers to help them understand the behavior, 
  43. performance, and structure of their application. If you are using 
  44. Visual Studio Analyzer on a computer that is running Windows 95, 
  45. you should always use this version of DCOM95.
  46.  
  47. New Directory Created by Setup
  48.  
  49. Setup creates a directory called DCOM95 under your system 
  50. directory. The end-user license agreement and other files  are 
  51. stored there. Setup also creates a subdirectory of DCOM95 called 
  52. OLDOLE, into which the old DCOM95 or OLE binaries are backed 
  53. up. These files are restored if you later uninstall DCOM95.
  54.  
  55. COM Internet Services
  56.  
  57. The COM Internet Services (CIS) enable clients and servers to be 
  58. connected over the Internet using COM. CIS consists of 
  59. *    A new DCOM protocol, Tunneled TCP 
  60. *    A new moniker type, OBJREF moniker 
  61. *    A new CISCNFG utility
  62.  
  63. For CIS client support in Windows 95, you must install both DCOM95 
  64. and DCOMCFG. Then use the CISCNFG tool, which is installed when you 
  65. install the DCOM configuration utility, to change the registry key 
  66. that defines which protocol to use for remote processes. In the 
  67. Command Prompt window, enter:
  68.     ciscnfg <protocol>
  69.  
  70. Where <protocol> is:
  71. *    rpc to use RPC
  72. *    http to use HTTP
  73. *    tcp_http to try TCP first and then, if the server times out, 
  74.     to try HTTP.
  75.  
  76. The ciscnfg command with no argument provides usage 
  77. information.
  78.  
  79. No SDK updates are required to use the Tunneled TCP protocol. 
  80.  
  81. There are a few updates for OBJREF monikers. 
  82.  
  83. CreateObjrefMoniker
  84.  
  85. Creates an OBJREF moniker based on a pointer to an object.
  86. WINOLEAPI CreateObjrefMoniker(
  87.     LPUNKNOWN pUnk, //Pointer to the object
  88.     LPMONIKER *ppMk //Address of pointer to OBJREF moniker
  89. );
  90.  
  91. Parameters
  92.  
  93. pUnk
  94.  
  95. Pointer to the IUnknown interface on the object that the moniker 
  96. is to represent.
  97.  
  98. ppMk
  99.  
  100. Address of a pointer to the IMoniker interface on the OBJREF 
  101. moniker created.
  102.  
  103. Return Values
  104.  
  105. This function supports the standard return values 
  106. E_OUTOFMEMORY and E_UNEXPECTED, as well as the 
  107. following:
  108.  
  109. S_OK
  110.  
  111. The OBJREF moniker was successfully created.
  112.  
  113. Remarks
  114.  
  115. Clients use OBJREF monikers to obtain a marshaled pointer to a 
  116. running object in the serverÆs address space. 
  117. The server typically calls CreateObjrefMoniker to create an 
  118. OBJREF moniker and then calls IMoniker::GetDisplayName, and 
  119. finally releases the moniker. The display name for an OBJREF 
  120. moniker is of the form:
  121.     OBJREF:nnnnnnnn 
  122.  
  123. Where nnnnnnnn is an arbitrarily long base-64 encoding that 
  124. encapsulates the machine location, process endpoint, and interface 
  125. pointer ID (IPID) of the running object. 
  126.  
  127. The display name can then be transferred to the client as text. For 
  128. example, the display name can reside on an HTML page that the 
  129. client downloads. 
  130.  
  131. The client can pass the display name to MkParseDisplayName, 
  132. which creates an OBJREF moniker based on the display name. A 
  133. call to the monikerÆs IMoniker::BindToObject method then obtains 
  134. a marshaled pointer to the running instance on the server. 
  135. For example, a server-side COM component contained in an active 
  136. server page can create an OBJREF moniker, obtain its display 
  137. name, and write the display name to the HTML output that is sent to 
  138. the client browser. A script that runs on the client side can use the 
  139. display name to get access to the running object itself. A client-side
  140. Visual Basic script, for instance, could store the display name in a 
  141. variable called strMyName and include this line:
  142.     objMyInstance = GetObject(strMyName)
  143.  
  144. The script engine internally makes the calls to 
  145. MkParseDisplayName and IMoniker::BindToObject, and the 
  146. script can then use objMyInstance to refer directly to the running 
  147. object.
  148.  
  149. If the running object uses static IPIDs and the server process 
  150. always runs on the same computer at a well-known endpoint, the 
  151. display name of the OBJREF moniker will always be the same. In 
  152. that case, the server can store the display name instead of 
  153. calculating it each time it receives a request for the object. 
  154.  
  155. IMoniker - OBJREF Moniker Implementation
  156.  
  157. OBJREF monikers represent a reference to an object instance that 
  158. is running on an out-of-process server, either locally or remotely. 
  159. The moniker identifies the object instance and the computer the 
  160. object is running on. 
  161.  
  162. An OBJREF moniker is similar in many ways to a pointer moniker, 
  163. except that the running object is out-of-process. A client can call 
  164. IMoniker::BindToObject on an OBJREF moniker and use the 
  165. pointer it obtains to access the running object, regardless of its 
  166. location. 
  167.  
  168. An important distinction from a pointer moniker is that the display 
  169. name of an OBJREF moniker can be embedded in an HTML page, 
  170. and the running object represented by the moniker can be bound by 
  171. a client script, applet, or ActiveX control.
  172.  
  173. When to Use
  174.  
  175. The primary use for an OBJREF moniker is to obtain access to a 
  176. running object instance over the Internet. An active server page or 
  177. some other means of generating dynamic HTML content places the 
  178. display name of an OBJREF moniker in a parameter to an applet or 
  179. an ActiveX control. The code of the applet or control calls 
  180. CreateObjrefMoniker to create an OBJREF moniker based on the 
  181. display name, and it then calls IMoniker::BindToObject on the 
  182. resulting OBJREF moniker to get access to the running object 
  183. instance. The active server page then marshals a pointer to the 
  184. running object back to the pageÆs client. 
  185.  
  186. Remarks
  187.  
  188. IMoniker::BindToObject. For OBJREF monikers, the pmkToLeft 
  189. parameter must be NULL. Because the OBJREF moniker 
  190. represents a running object, no activation takes place. If the 
  191. represented object is no longer running, BindToObject fails with 
  192. E_UNEXPECTED. 
  193.  
  194. IMoniker::BindToStorage. This method obtains a marshaled 
  195. pointer to the requested interface on the storage that contains the 
  196. running object. Because the OBJREF moniker represents a running 
  197. object, no activation takes place. If the represented object is no 
  198. longer running, BindToStorage fails with E_UNEXPECTED. 
  199.  
  200. IMoniker::Reduce. This method returns 
  201. MK_S_REDUCED_TO_SELF and passes back the same moniker.
  202.  
  203. IMoniker::ComposeWith. If pmkRight is an anti-moniker, the 
  204. returned moniker is NULL. If pmkRight is a composite whose 
  205. leftmost component is an anti-moniker, the returned moniker is the 
  206. composite with the leftmost anti-moniker removed. If pmkRight is 
  207. neither an anti-moniker nor a composite moniker whose leftmost 
  208. component is an anti-moniker, then the method checks the 
  209. fOnlyIfNotGeneric parameter. If it is FALSE, the method combines 
  210. the two monikers into a generic composite; if it is TRUE, the method 
  211. sets *ppmkComposite to NULL and returns 
  212. MK_E_NEEDGENERIC.
  213.  
  214. IMo